iT邦幫忙

2025 iThome 鐵人賽

DAY 3
2
生成式 AI

從 RAG 到 Agentic RAG:30 天打造本機智慧檢索系統系列 第 3

Day 3: 資料處理與知識庫模組-PDF parsing與Chunking

  • 分享至 

  • xImage
  •  

在前一篇文章的最後面,我們介紹了 RAG 的架構分層有分為 1. 資料處理與知識庫模組和 2. 使用者查詢與生成模組。
接下來,我們要開始進入資料處理與知識庫模組中的資料處理
這個階段的目標是將文件轉換為可被檢索的結構化知識,並最終存入向量資料庫中。今天的重點會放在 PDF ParsingChunking 策略


📄PDF Parsing

1. 為什麼要處理 PDF?

在真實場景中,企業知識大多以 PDF 文件 形式存在,例如:合約、研究報告、產品規格書、財務文件。而要讓你的RAG讀懂這些知識,我們需要先將這些檔案的內容萃取出來,為放入向量資料庫做準備,我們稱為PDF Parsing。
筆者認為裡面的關鍵技術有兩個:

  • 文字抽取:PDF 本質是版面格式,透過一些PDF處理技術或OCR套件可實踐。
  • 表格抽取:許多關鍵資訊(例如財務數據、技術規格)存在於表格中,如何有效提取是一個挑戰。

為什麼沒提到圖片呢?因為筆者的經驗中,許多知識文件的圖是用來讓人更好理解文字的,但要描述的內容其實文件都會提到,因此比較少遇到真的需要對圖片做提取的狀況。


2. PDF Parsing 工具選擇

市面上有許多不同的,非常推薦ihower大大做的筆記:
Parsing PDF
筆者在這邊不對所有工具做介紹,有興趣的可以參考上面的連結,這邊只先推薦一下自己在地端運作時主要使用的PDF Parsing套件,在週末的實作中也會實際操作示範:

  1. PyPDF

    • 優點:繁中擷取穩定,圖表內有含文字也會被讀出。
    • 缺點:對複雜排版與表格很容易誤判,導致資訊萃取錯誤。
    • 適用場景:一般文字型 PDF。
  2. img2table

    • 專門處理表格型資料,能將表格結構轉換為 DataFrame,更重要的是能處理複雜表格。
    • 適用場景:財報、規格書、研究數據表。

📌 建議策略:混合使用 —— 先判斷表格和圖,將文字與其分開處理。用 PyPDF 抽文字,用img2table處理表格。

🧩Chunking 策略

在處理 PDF 或其他大型文件時,光是完成 parsing 還不夠,我們還需要將長文 切分(chunking),才能讓後續的向量化與檢索更精準。這個步驟的設計會直接影響 RAG 的檢索品質與效能,大家都非常在意,但還沒有一個通用的最佳解法。

1. 為什麼要做 Chunking?

  • 應對長度不均:現實中的文件往往長短不一,切分能確保處理方式一致。
  • 克服模型限制:多數 embedding/LLM 模型有最大 token 限制,切分讓我們能處理超長文本。
  • 提升表示品質:避免 embedding 一次要涵蓋過多訊息,讓每個 chunk 更聚焦。
  • 增強檢索精度:較小的單元能讓檢索結果更細緻,更容易匹配到正確上下文。
  • 資源效率:較小的 chunk 可以更好地並行處理,減少記憶體與計算負擔。

2. 常見 Chunking 策略(我們參考LangChain的分類)

1. 📏 長度導向(Length-based)

  • 概念:依固定長度來切分,最常見的方法。
  • 方式
    • Token-based:依 token 數量切分(常見於 LLM 任務)。
    • Character-based:依字元長度切分(對不同文本較穩定)。
  • 優點:簡單、穩定、可依模型需求調整。
  • 缺點:可能打斷語意,造成上下文被切碎。

2. 📚 文本結構導向(Text-structured)

  • 概念:利用語言本身的結構來切分,例如段落、句子、甚至詞。
  • 典型做法:LangChain 的 RecursiveCharacterTextSplitter
    • 優先保留較大的單位(段落)
    • 如果過長,再往下拆成句子或詞
  • 優點:能保持語言的自然流暢與語意連貫。

3. 🏗️ 文件結構導向(Document-structured)

  • 概念:針對有明顯結構的文件(Markdown、HTML、JSON、程式碼)依照格式切分。
  • 例子
    • Markdown:依照標題(######
    • HTML:依標籤 <div><p>
    • JSON:依物件或陣列元素
    • Code:依函數、class 或邏輯區塊
  • 優點:保留文件邏輯脈絡,對於後續檢索或摘要特別有幫助。

4. 🧠 語意導向(Semantic-based)

  • 概念:根據內容語意來切分,而不是純結構。
  • 常見方式:滑動窗口 + embedding 相似度
    • 先為一小段文字產生 embedding
    • 移動到下一段並比較相似度
    • 發現語意差異較大時,就視為斷點
  • 優點:更符合人類理解單位,檢索精準度高
  • 缺點:計算成本較高,需要 embedding 運算與相似度判斷

實務建議

沒有一種策略能通吃所有場景,通常會依 文件特性與應用需求 來調整,筆者甚至會直接用頁數來做chunking,或是直接將文字和表格分開,周末實作我們再一起看一些範例。


📖 延伸閱讀


👉 接下來,當我們有了合適的 Chunking 結果,就能進入下一步:將文字轉換成向量(Embedding),並存入向量資料庫中。這會是下一篇的主題,再請大家一起前進囉!


上一篇
Day 2: 為什麼要還要寫RAG? Fine-Tuning不香嗎?
下一篇
Day 4: 為什麼要做 Embedding? 又為什麼重要?
系列文
從 RAG 到 Agentic RAG:30 天打造本機智慧檢索系統6
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言